Search Results: "spwhitton"

9 January 2017

Sean Whitton: jan17vcspkg

There have been a two long threads on the debian-devel mailing list about the representation of the changes to upstream source code made by Debian maintainers. Here are a few notes for my own reference. I spent a lot of time defending the workflow I described in dgit-maint-merge(7) (which was inspired by this blog post). However, I came to be convinced that there is a case for a manually curated series of patches for certain classes of package. It will depend on how upstream uses git (rebasing or merging) and on whether the Debian delta from upstream is significant and/or long-standing. I still think that we should be using dgit-maint-merge(7) for leaf or near-leaf packages, because it saves so much volunteer time that can be better spent on other things. When upstream does use a merging workflow, one advantage of the dgit-maint-merge(7) workflow is that Debian s packaging is just another branch of development. Now consider packages where we do want a manually curated patch series. It is very hard to represent such a series in git. The only natural way to do it is to continually rebase the patch series against an upstream branch, but public branches that get rebased are not a good idea. The solution that many people have adopted is to represent their patch series as a folder full of .diff files, and then use gbp pq to convert this into a rebasing branch. This branch is not shared. It is edited, rebased, and then converted back to the folder of .diff files, the changes to which are then committed to git. One of the advantages of dgit is that there now exists an official, non-rebasing git history of uploads to the archive. It would be nice if we could represent curated patch series as branches in the dgit repos, rather than as folders full of .diff files. But as I just described, this is very hard. However, Ian Jackson has the beginnings of a workflow that just might fit the bill.

8 January 2017

Bits from Debian: New Debian Developers and Maintainers (November and December 2016)

The following contributors got their Debian Developer accounts in the last two months: The following contributors were added as Debian Maintainers in the last two months: Congratulations!

31 December 2016

Sean Whitton: Burkeman on time management

Burkeman: Why time management is ruining our lives Over the past semester I ve been trying to convince one graduate student and one professor in my department to use Inbox Zero to get a better handle on their e-mail inboxes. The goal is not to be more productive. The two of them get far more academic work done than I do. However, both of them are far more stressed than I am. And in the case of the graduate student, I have to add items to my own to-do list to chase up e-mails that I ve sent him, which only spreads this stress and tension around. The graduate student sent me this essay by Oliver Burkeman about how these techniques can backfire, creating more stress, tension and anxiety. It seems to me that this happens when we think of these techniques as having anything to do with productivity. Often people will say use this technique and you ll be less stressed, more productive, and even more productive because you re less stressed. Why not just say use this technique and you ll be less anxious and stressed ? This is a refusal to treat lower anxiety as merely a means to some further end. People can autonomously set their own ends, and they ll probably do a better job of this when they re less anxious. Someone offering a technique to help with their sense of being overwhelmed need not tell them what to do with their new calm. It might be argued that this response to Burkeman fails to address the huge sense of obligation that an e-mail inbox can generate. Perhaps the only sane response to this infinite to-do list is to let it pile up. If we follow a technique like Inbox Zero, don t we invest our inbox with more importance than it has? Like a lot of areas of life, the issue is that the e-mails that will advance truly valuable projects and relationships, projects of both ourselves and of others, are mixed in with reams of stuff that doesn t matter. We face this situation whenever we go into a supermarket, or wonder what to do during an upcoming vacation. In all these situations, we have a responsibility to learn how to filter the important stuff out, just as we have a responsibility to avoid reading celebrity gossip columns when we are scanning through a newspaper. Inbox Zero is a technique to do that filtering in the case of e-mail. Just letting our inbox pile up is an abdication of responsibility, rather than an intelligent response to a piece of technology that most of the world abuses.

18 December 2016

Sean Whitton: progpoking

Programming by poking: why MIT stopped teaching SICP Perhaps there is a case for CS programs keeping pace with workplace technological changes (in addition to developments in the academic field of CS), but it seems sad to deprive undergrads of deeper knowledge about language design.

23 October 2016

Jaldhar Vyas: What I Did During My Summer Vacation

Thats So Raven If I could sum up the past year in one word, that word would be distraction. There have been so many strange, confusing or simply unforseen things going on I have had trouble focusing like never before. For instance, on the opposite side of the street from me is one of Jersey City's old resorvoirs. It's not used for drinking water anymore and the city eventually plans on merging it into the park on the other side. In the meantime it has become something of a wildlife refuge. Which is nice except one of the newly settled critters was a bird of prey -- the consensus is possibly some kind of hawk or raven. Starting your morning commute under the eyes of a harbinger of death is very goth and I even learned to deal with the occasional piece of deconstructed rodent on my doorstep but nighttime was a big problem. For contrary to popular belief, ravens do not quoth "nevermore" but "KRRAAAA". Very loudly. Just as soon as you have drifted of to sleep. Eventually my sleep-deprived neighbors and I appealed to the NJ division of enviromental protection to get it removed but by the time they were ready to swing into action the bird had left for somewhere more congenial like Transylvania or Newark. Or here are some more complete wastes of time: I go the doctor for my annual physical. The insurance company codes it as Adult Onset Diabetes by accident. One day I opened the lid of my laptop and there's a "ping" sound and a piece of the hinge flies off. Apparently that also severed the connection to the screen and naturally the warranty had just expired so I had to spend the next month tethered to an external monitor until I could afford to buy a new one. Mix in all the usual social, political, family and work drama and you can see that it has been a very trying time for me. Dovecot I have managed to get some Debian work done. On Dovecot, my principal package, I have gotten tremendous support from Apollon Oikonomopolous who I belatedly welcome as a member of the Dovecot maintainer team. He has been particularly helpful in fixing our systemd support and cleaning out a lot of the old and invalid bugs. We're in pretty good shape for the freeze. Upstream has released an RC of 2.2.26 and hopefully the final version will be out in the next couple of days so we can include it in Stretch. We can always use more help with the package so let me know if you're interested. Debian-IN Most of the action has been going on without me but I've been lending support and sponsoring whenever I can. We have several new DDs and DMs but still no one north of the Vindhyas I'm afraid. Debian Perl Group gregoa did a ping of inactive maintainers and I regretfully had to admit to myself that I wasn't going to be of use anytime soon so I resigned. Perl remains my favorite language and I've actually been more involved in the meetings of my local Perlmongers group so hopefully I will be back again one day. And I still maintain the Perl modules I wrote myself. Debian-Axe-Murderers* May have gained a recruit. *Stricly speaking it should be called Debian-People-Who-Dont-Think-Faults-in-One-Moral-Domain-Such-As-For-Example-Axe-Murdering-Should-Leak-Into-Another-Moral-Domain-Such-As-For-Example-Debian but come on, that's just silly.

28 September 2016

Sean Whitton: 'Do you really need to do that?'

A new postdoc student arrived at our department this semester, and after learning that he uses GNU/Linux for all his computing, I invited him along to TFUG. During some of our meetings people asked how could I do X on my GNU/Linux desktop? and, jokingly, the postdoc would respond the answer to your question is do you really need to do that? Sometimes the more experienced GNU/Linux users at the table would respond to questions by suggesting that the user should simply give up on doing X, and the postdoc would slap his thigh and laugh and say see? I told you that s the answer! The phenomenon here is that people who have at some point made a commitment to at least try to use GNU/Linux for all their computing quickly find that they have come to value using GNU/Linux more than they value engaging in certain activities that only work well/at all under a proprietary operating system. I think that this is because they get used to being treated with respect by their computer. And indeed, one of the reasons I ve almost entirely given up on computer gaming is that computer games are non-free software. Are you sure you need to do that? starts sounding like a genuine question rather than simply a polite way of saying that what someone wants to do can t be achieved. I suggest that this is a blessing in disguise. The majority of the things that you can only do under a proprietary operating system are things that it would be good for you if you were to switch them out for other activities. I m not suggesting that switching to a GNU/Linux is a good way to give up on the entertainment industry. It s a good way of moderating your engagement with the entertainment industry. Rather than logging onto Netflix, you might instead pop in a DVD of a movie. You can still engage with contemporary popular culture, but the technical barriers give you an opportunity to moderate your consumption: once you ve finished watching the movie, the software won t try to get you to watch something else by making a calculation as to what you re most likely to assent to watching next based on what you ve watched before. For this behaviour of the Netflix software is just another example of non-free software working against its user s interests: watching a movie is good for you, but binge-watching a TV series probably isn t. In cases like this, living in the world of Free Software makes it easier to engage with media healthily.

21 September 2016

Sean Whitton: Boards in the philosophy dept. yesterday

Compare

17 August 2016

Sean Whitton: Tucson monsoon rains

When it rains in Tucson, people are able to take an unusually carefree attitude towards it. Although the storm is dramatic, and the amount of water means that the streets turn to rivers, everyone knows that it will be over in a few hours and the heat will return (and indeed, that s why drain provision is so paltry). In other words, despite the arresting thunderclaps, the weather is not threatening. By contrast, when there is a storm in Britain, one feels a faint primordial fear that one won t be able to find shelter after the storm, in the cold and sodden woods and fields. Here, that threat just isn t present. I think that s what makes us feel so free to move around in the rain. I rode my bike back from the gym in my $5 plastic shoes. The rain hitting my body was cold, but the water splashing up my legs and feet was warm thanks of the surface of the road except for one area where the road was steep enough that the running water had already taken away all lingering heat.

6 August 2016

Sean Whitton: git-push-all

I maintain Debian packages for several projects which are hosted on GitHub. I have a master packaging branch containing both upstream s code, and my debian/ subdirectory containing the packaging control files. When upstream makes a new release, I simply merge their release tag into master: git merge 1.2.3 (after reviewing the diff!). Packaging things for Debian turns out to be a great way to find small bugs that need to be fixed, and I end up forwarding a lot of patches upstream. Since the projects are on GitHub, that means forking the repo and submitting pull requests. So I end up with three remotes:
origin
the Debian git server
upstream
upstream s GitHub repo from which I m getting the release tags
fork
my GitHub fork of upstream s repo, where I m pushing bugfix branches
I can easily push individual branches to particular remotes. For example, I might say git push -u fork fix-gcc-6. However, it is also useful to have a command that pushes everything to the places it should be: pushes bugfix branches to fork, my master packaging branch to origin, and definitely doesn t try to push anything to upstream (recently an upstream project gave me push access because I was sending so many patches, and then got a bit annoyed when I pushed a series of Debian release tags to their GitHub repo by mistake). I spent quite a lot of time reading git-config(1) and git-push(1), and came to the conclusion that there is no combination of git settings and a push command that do the right thing in all cases. Candidates, and why they re insufficient:
git push --all
I thought about using this with the remote.pushDefault and branch.*.pushRemote configuration options. The problem is that git push --all pushes to only one remote, and it selects it by looking at the current branch. If I ran this command for all remotes, it would push everything everywhere.
git push <remote> : for each remote
This is the matching push strategy . It will push all branches that already exist on the remote with the same name. So I thought about running this for each remote. The problem is that I typically have different master branchs on different remotes. The fork and upstream remotes have upstream s master branch, and the origin remote has my packaging branch.
I wrote a perl script implementing git push-all, which does the right thing. As you will see from the description at the top of the script, it uses remote.pushDefault and branch.*.pushRemote to determine where it should push, falling back to pushing to the remote the branch is tracking. If won t push something when all three of these are unspecified, and more generally, it won t create new remote branches except in the case where the branch-specific setting branch.*.pushRemote has been specified. Magit makes it easy to set remote.pushDefault and branch.*.pushRemote. I have this in my ~/.mrconfig:
git_push = git push-all
so that I can just run mr push to ensure that all of my work has been sent where it needs to be (see myrepos).
#!/usr/bin/perl
# git-push-all -- intelligently push most branches
# Copyright (C) 2016 Sean Whitton
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
# Prerequisites:
# The Git::Wrapper, Config::GitLike, and List::MoreUtils perl
# libraries.  On a Debian system,
#     apt-get install libgit-wrapper-perl libconfig-gitlike-perl \
#         liblist-moreutils-perl
# Description:
# This script will try to push all your branches to the places they
# should be pushed, with --follow-tags.  Specifically, for each branch,
#
# 1. If branch.pushRemote is set, push it there
#
# 2. Otherwise, if remote.pushDefault is set, push it there
#
# 3. Otherwise, if it is tracking a remote branch, push it there
#
# 4. Otherwise, exit non-zero.
#
# If a branch is tracking a remote that you cannot push to, be sure to
# set at least one of branch.pushRemote and remote.pushDefault.
use strict;
use warnings;
no warnings "experimental::smartmatch";
use Git::Wrapper;
use Config::GitLike;
use List::MoreUtils qw  uniq apply  ;
my $git = Git::Wrapper->new(".");
my $config = Config::GitLike->new( confname => 'config' );
$config->load_file('.git/config');
my @branches = apply   s/[ \*]//g   $git->branch;
my @allBranches = apply   s/[ \*]//g   $git->branch(  all => 1  );
my $pushDefault = $config->get( key => "remote.pushDefault" );
my %pushes;
foreach my $branch ( @branches )  
    my $pushRemote = $config->get( key => "branch.$branch.pushRemote" );
    my $tracking = $config->get( key => "branch.$branch.remote" );
    if ( defined $pushRemote )  
        print "I: pushing $branch to $pushRemote (its pushRemote)\n";
        push @  $pushes $pushRemote   , $branch;
    # don't push unless it already exists on the remote: this script
    # avoids creating branches
      elsif ( defined $pushDefault
              && "remotes/$pushDefault/$branch" ~~ @allBranches )  
        print "I: pushing $branch to $pushDefault (the remote.pushDefault)\n";
        push @  $pushes $pushDefault   , $branch;
      elsif ( !defined $pushDefault && defined $tracking )  
        print "I: pushing $branch to $tracking (probably to its tracking branch)\n";
        push @  $pushes $tracking   , $branch;
      else  
        die "E: couldn't find anywhere to push $branch";
     
 
foreach my $remote ( keys %pushes )  
    my @branches = @  $pushes $remote   ;
    system "git push --follow-tags $remote @branches";
    exit 1 if ( $? != 0 );
 

30 July 2016

Sean Whitton: internetcomments

This doesn t appear to cover the other kind of comment-moderation problem: that where overmoderation and attachment to poster identity leads to an environment of stifling conventionalism. Photography communities in particular (e.g. flickr, instagram, 500px) are vulnerable to turning into circlejerks where no-one is willing to say what they mean for fear of appearing the negative nancy (no pun intended) and where high post-count contributors poorly-supported opinions become elevated above said views merits. In such communities the typical discussion is at the level of tepid platitude: good exposure! , nice depth of field! , or cool HDR! . On the other end of the scale there s the imageboard style of community where anonymity is the norm, feedback is uncompromisingly harsh, and uselessly opaque criticism appears such on its face; unsuited to the overly sensitive but hideously valuable to the advancing novice. Ordinary web forums, with tools oriented towards a punitive he said the n-word! delete his account and everything he s posted! persona non grata, in damnatio memoriae! school of moderation, strongly tend to the former.
ksandstr on LWN

7 July 2016

Sean Whitton: Kant and tear gas

Over the past year I ve been refining my understanding of the core claims of Kantian ethics. I ve realised that I have deeply Kantian intuitions about a lot of issues, and I understand these intuitions better now that I can put them in Kantian terms. Consider two exercises of state power: riot police suppressing protesters by non-lethal means, and soldiers shooting protesters to death. I feel more uncomfortable thinking about the first: there s something altogether more sinister about it than the second, even though the second is much more sad. I think that the reason is that non-lethal weaponry is designed to take away people s agency, and it often achieves this aim by means of emotional manipulation. Riot police use so-called baton charges to incite fearful retreat. Protesters have reasoned that in their political situation, they have a duty to resist the incumbent government. Riot police seek to unseat this conviction and cause fear to determine what the protesters will do. In Kantian terms, the riot police fail to respect the moral agency of the protesters by seeking to unseat the moral personality s determination of what the protester will do. A controversial example that Kant uses to make this point is the axe murderer case. Kant asks us to imagine that someone bangs on our front door and begs us to hide him in our house, because someone who wishes to kill him is coming up behind them. We do so. When the axe murderer arrives, he goes door-to-door and asks us whether the intended victim is in each house. Kant says that it is morally wrong to lie to the axe murderer and say that the victim is not in your house. How could this be? Surely there is a moral duty to protect the victim from being killed? Indeed there is, but when it comes into conflict with the duty not to lie, that second duty wins out. That s because respecting the moral agency of individuals is paramount. In this case, we would fail to respect the murderer s agency if we didn t allow him to take the decision to murder or not murder the victim; by lying to him we (disrespectfully) bypass his choice as to whether to do it. It s obviously crazy to say that we are morally required to give up the victim. Kant gives the wrong answer in this case. However, the case definitely reveals a requirement to respect other people s view of what they should do, and give them a chance to do it. Similarly it seems like we shouldn t give semi-automatics to our riot police, but there s something wrong with a lot of what they do. During the recent campaigns about Britain s EU referendum, some criticised Jeremy Corbyn s campaigning on the grounds that he failed to make an emotional appeal, instead asking people to make their own rational decision when they come to cast their vote. So he lost out the emotional appeals other people were making. It seems that he was successfully respecting individual agency. You ve got to give people a chance to live up to their own idea of what they should do. I m not sure how to reconcile these various ideas, and I m not sure what it says about me that I find non-lethal weaponry as uncomfortable as I do.

30 June 2016

Sean Whitton: bucheontimestop

This summer I m living in a flat five minutes walk from Bucheon station, near Seoul. Today there is a threat of rain and it s very humid, which tends to make one feel that time has stopped: it s as if everyone and everything is waiting for the rain to fall before getting on with their lives. There are two other reasons why one might think that time has stopped. There is a household goods shop outside the station that has a poster up which says last day of business , but of course it says this every day. A few weeks ago it said last three days of business instead, but they must have decided that was starting to look implausible or something. They do various things to look like they re struggling to get rid of their wares. The other day they just piled everying up in a huge pile on the street outside the shop. They have a guy with a megaphone shouting all day about how cheap everything is in an urgent tone. The other reason to think time has stopped is that today s coffee in Starbucks is always the same coffee. On the little blackboard that all Starbucks branches have they have written: now brewing: hot: iced coffee blend. iced: iced coffee blend. Every time I order a cup of today s coffee I have to wait five minutes while they actually brew it because it seems like no-one else is ordering it. And it tastes exactly the same as yesterday s coffee.

8 June 2016

Francois Marier: Simple remote mail queue monitoring

In order to monitor some of the machines I maintain, I rely on a simple email setup using logcheck. Unfortunately that system completely breaks down if mail delivery stops. This is the simple setup I've come up with to ensure that mail doesn't pile up on the remote machine.

Server setup The first thing I did on the server-side is to follow Sean Whitton's advice and configure postfix so that it keeps undelivered emails for 10 days (instead of 5 days, the default):
postconf -e maximal_queue_lifetime=10d
Then I created a new user:
adduser mailq-check
with a password straight out of pwgen -s 32. I gave ssh permission to that user:
adduser mailq-check sshuser
and then authorized my new ssh key (see next section):
sudo -u mailq-check -i
mkdir ~/.ssh/
cat - > ~/.ssh/authorized_keys

Laptop setup On my laptop, the machine from where I monitor the server's mail queue, I first created a new password-less ssh key:
ssh-keygen -t ed25519 -f .ssh/egilsstadir-mailq-check
cat ~/.ssh/egilsstadir-mailq-check.pub
which I then installed on the server. Then I added this cronjob in /etc/cron.d/egilsstadir-mailq-check:
0 2 * * * francois /usr/bin/ssh -i /home/francois/.ssh/egilsstadir-mailq-check mailq-check@egilsstadir mailq   grep -v "Mail queue is empty"
and that's it. I get a (locally delivered) email whenever the mail queue on the server is non-empty. There is a race condition built into this setup since it's possible that the server will want to send an email at 2am. However, all that does is send a spurious warning email in that case and so it's a pretty small price to pay for a dirt simple setup that's unlikely to break.

30 May 2016

Sean Whitton: Skype inside Firejail version 0.9.40-rc1

Since my PGP key is on its way into the Debian Maintainers keyring, I feel that I should be more careful about computer security. This week I find that I need to run Skype in order to make some calls to some landlines. With the new release candidate of Firejail, it s really easy to minimise the threat from its non-free code. Firstly, check that the Skype .deb you download from their website merely installs files and does not run any prerm or postinst scripts. You can run dpkg-deb --control skype-debian_4.3.0.37-1_i386.deb and confirm that there s nothing executable in there. You should also list the contents with dpkg-deb --contents skype-debian_4.3.0.37-1_i386.deb, and confirm that it doesn t install anything to places that will be executed by the system, such as to /etc/cron.d. For my own reference the safe .deb has sha256 hash a820e641d1ee3fece3fdf206f384eb65e764d7b1ceff3bc5dee818beb319993c, but you should perform these checks yourself. Then install Firejail and Xephyr. You can hook Firejail and Xephyr together manually, but Firejail version 0.9.40-rc1 can do it for you, which is very convenient, so we install that from the Debian Experimental archive:
# apt-get install xserver-xephyr firejail/experimental
Here s an invocation to use the jail:
$ firejail --x11=xephyr --private --private-tmp openbox
$ DISPLAY=$(firemon --x11   grep "DISPLAY"   sed 's/   DISPLAY //') \
  firejail --private --private-tmp skype
This takes advantage of Firejail s existing jail profile for Skype. We get the following: This isn t perfect. An annoyance is that the Xephyr window sticks around when you close Skype. More seriously, computer security is always an attacker s advantage game, so this is just an attempt at reducing (optimistically: minimising) the threat posed by non-free code. Update 2016/vi/1: use openbox

17 May 2016

Sean Whitton: seoulviasfo

I spent last night in San Francisco on my way from Tucson to Seoul. This morning as I headed to the airport, I caught the end of a shouted conversation between a down-and-out and a couple of middle school-aged girls, who ran away back to the Asian Art museum as the conversation ended. A security guard told the man that he needed him to go away. The wealth divide so visible here just isn t something you really see around Tucson. I m working on a new module for Propellor that s complicated enough that I need to think carefully about the Haskell in order to write produce a flexible and maintainable module. I ve only been doing an hour or so of work on it per day, but the past few days I wake up each day with an idea for restructuring yesterday s code. These ideas aren t anything new to me: I think I m just dredging up the understanding of Haskell I developed last year when I was studying it more actively. Hopefully this summer I can learn some new things about Haskell. Riding on the Bay Area Rapid Transit (BART) feels like stepping back in time to the years of Microsoft s ascendency, before we had a tech world dominated by Google and Facebook: the platform announcements are in a computerised voice that sounds like it was developed in the nineties. They ll eventually replace the old trains apparently some new ones are coming in 2017 so I feel privileged to have been able to ride the older ones. I feel the same about the Tube in London. I really appreciate old but supremely reliable and effective public transport. It reminds me of the Debian toolchain: a bit creaky, but maintained over a sufficiently long period that it serves everyone a lot better than newer offerings, which tend to be produced with ulterior corporate motives.

5 May 2016

Sean Whitton: dh_make_elpa & dh_elpa_test

I recently completed and released some work on Debian s tooling for packaging Emacs Lisp addons to GNU Emacs. Emacs grew a package manager called package.el a few years ago, and last year David Bremner wrote the dh_elpa tool to simplify packaging addons for Debian by leveraging package.el features. Packaging a series of addons for Debian left me with a wishlist of features for dh_elpa and I was recently able to implement them. Debian tooling generally uses Perl, a language I didn t know before starting on this project. I was fortunate enough to receive a free review copy of Perl 5 by Example when I attended a meeting of the Bay Area Linux Users Group while I was visiting San Francisco a few months ago. I accepted the book with the intent of doing this work. dh_make_elpa dh_make_elpa (at present available from Debian experimental) is a Perl script to convert a git repository cloned from the upstream of an Emacs Lisp addon to a rudimentary Debian package. It performs a lot of guesswork, and its simple heuristics are something I hope to improve on. Since I am new to object-oriented program design in Perl and I wanted to leverage object-oriented Debian tooling library code, I took the structure of my project from dh_make_perl. In this manner I found it easy and pleasant to write a maintainable script. dh_elpa_test A lot of Emacs Lisp addon packages use a program called Cask to manage the Emacs Lisp dependencies needed to run their test suites. That meant that dh_auto_test often fails to run Emacs Lisp addon package test suites. Since the Debian packaging toolchain already has advanced dependency management, it s undesirable to involve Cask in the package build pipeline if it can be avoided. I had been copying and pasting the code needed to make the tests run in our environment to the debian/rules files of each package whose test suite I wanted to run. dh_elpa_test tries to detect Emacs Lisp addon package test suites and run them with the workarounds needed in our environment. This avoids boilerplate in debian/rules. dh_elpa_test also disables dh_auto_test to avoid a inadvertent Cask invocation. Future & acknowledgements My hope for this work was to make it easier and faster to package Emacs Lisp addon packages for Debian, for my own sake and for anyone new who is interested in joining the pkg-emacsen team. In the future, I want to have dh_elpa_test generate an autopkgtest definition so that a Testsuite: pkg-emacsen line in debian/control is enough to have an Emacs Lisp addon package test suite run on Debian CI. I m very grateful to David Bremner for reviewing and supporting this work, and also for supporting my Emacs Lisp addon packaging work more generally.

17 April 2016

Sean Whitton: Mail expiring out of the postfix mail queue

On my Debian machines I run stunnel to create an secure connection to my e-mail provider s SMTP gateway. Postfix sends mail through that TLS tunnel. Recently I stopped receiving e-mail from rss2email and I discovered tonight that the reason was that the tunnel has caved in on the machine which rss2email was running on. Unfortunately, some mail was permanently discarded from the postfix queue because it turns out that postfix will by default keep mail in the queue for a maximum of only 5 days. Since the connection to the gateway was down, postfix couldn t return the mail to its sender (i.e. me). Fortunately, I m not smart enough to have any log rotation going on, so I could easily find the message that were lost:
grep "status=expired, returned to sender" /var/log/mail.log \
      awk ' print $6 ' \
      while read id; do grep "$id" -m1 /var/log/mail.log; done
The first grep determines the queue id of the messages that were expired, and then the second grep finds the first entry in the mail log for that message, which provides the time the message was sent. Replacing -m1 with -m4 gave me the message-id of the messages and the intended recipient of the messages. This allowed me to restore them from backups or bounce them from my sent mail folder for those that I tried to send myself. To prevent this from happening again, I ve extended the maximum lifetime of messages in the queue from 5 days to 10:
postconf -e maximal_queue_lifetime=10d
I ve incorporated a check for clogged mail queues on my machines into my weekly backup routine.

25 March 2016

Sean Whitton: A standing desk that looks a bit like it's made of LEGO bricks

Making a big difference to my neck and back pain after just a week!

20 March 2016

Sean Whitton: Spring Break in San Francisco

Last night I got back from spending around 5 days in the Bay Area for Spring Break. I stayed in a hostel in downtown SF for three nights and then I stayed with a friend who is doing a PhD at Stanford. When initially planning this trip my aim was just to visit somewhere interesting on the west coast of the continental United States. I chose the Bay Area because I wanted to get my PGP key signed by some Debian Developers and that area has a high concentration of DDs, and because I wanted to see my friend at Stanford. But in the end I liked San Francisco a lot more than expected to and am very glad that I had an opportunity to visit. The first thing that I liked was how easy it seemed to be to find people interested in the same kind of tech stuff that I am. I spent my first afternoon in the city exploring the famous Mission district, and at one point while sitting in the original Philz Coffee I found that the person sitting next to me was running Debian on her laptop and blogs about data privacy. We had an discussion about how viable OpenPGP is as a component of a technically unsophisticated user s attempts to stay safe online. Later that same day while riding the subway train, someone next to me fired up Emacs on their laptop. And over the course of my trip I met five Debian Developers doing all sorts of different kinds of work both in and outside of Debian, and some Debian users including one of Stanford s UNIX sysadmins. This is a far cry from my day-to-day life down in the Sonoran Desert where new releases of iOS are all anyone seems to be interested in. Perhaps I should have expected this before my trip, but I think I had assumed that most of the work being done in San Francisco was writing web apps, so I was pleased to find people working on the same kind of things that I am currently putting time into. And in saying the above, I don t mean to demean the interests of the people around me in Arizona for a moment (nor those writing web apps; I d like to learn how to write good ones at some point). I m very grateful to be able to discuss my philosophical interests with the other graduate students. It s just that I miss being able to discuss tech stuff. I guess you can t have everything you want! One particular encouraging meeting I had was with a Debian Developer employed by Google and working on Git. While my maths background sets me up with the right thinking skills to write programs, I don t have knowledge typically gained from an education in computer science that enables one to work on the most interesting software. In particular, low-level programming in C is something that I had thought it wouldn t be possible for me to get started with. So it was encouraging to meet the DD working on Git at Google because his situation was similar: his undergraduate background is in maths and he was able to learn how to code in C by himself and is now working on a exciting project at a company that it is hard to get hired by. I don t mean that doing exactly what he s doing is something that I aiming for, just that it is very encouraging to know the field is more open to me than I had thought. I was also reminded of how fortunate I am to have the Internet to learn from and projects like Debian to get involved with. Moving on from tech, I enjoyed the streets of San Francisco, and the Stanford campus. San Francisco is fantastically multicultural though with clear class and wealth divisions. A very few minutes walk from the Twitter headquarters with its tech bros , as the maths PhD students I met at Stanford call them, are legions of the un- and barely-employed passing their time on the concrete. I enjoyed riding one of the old cable cars through the aesthetically revealing and stark combination of a west coast grid system on some very steep hills. I was fortunate to be able to walk across the Golden Gate Bridge on a perfectly clear and mist-free day. Meeting people involved with Debian and meeting my old friend at Stanford had me reflecting on and questioning my life in the desert even more than usual. I try to remind myself that there is an end date in sight and I will regret spending my time here just thinking about leaving. I sometimes worry that I could easily find myself moving to the big city London, San Francisco or elsewhere and letting myself be carried by the imagined self-importance of that, sidelining and procrastinating things that I should prize more highly. I should remember that the world of writing software in big cities isn t going away and my time in the desert is an opportunity to prepare myself better for that, building my resistance to being swept away by the tides of fashion.

14 February 2016

Sean Whitton: East 5th Street tech

There are three of us living here, and the plan is to switch all three of us from wireless to wired ethernet Internet connections by transporting cabling through the ventilation system using this remote-controlled car. Here s an action shot we took. My housemate put on his Gaming playlist and it reached a very suitable crescendo as we guided the car through its final journey, pulling the last piece of cotton which we would then use to pull the final cabal through. The timing of the music couldn t have been better. It reflected the risk of losing control of the car as we moved the controller around to enable the car to pick up the radio signals. A further risk was caused by the car only being able to turn right, not left, and there not being enough room in the air duct for it to make a full-circle rotation. Our backup plan was to try tossing a ball tied to a piece of string down the duct. Unfortunately I m still on a wireless connection because to reach my room we d have had to send the cable via the furnace/air conditioning unit which we decided against. Does a SATA-to-USB converter, for moving data off my old laptop hard drive which I had to replace this week, need to be this complicated?

Next.

Previous.